This will make the test fragile. Any time we change these CSS properties, the test will break. I recommend choosing a thing or two that is semantically meaningful for the line numbers. For instance, text-align should always be right; if we miss that, things will look bad.

Also, can we check that the contents are a number? Maybe a specific number, like 1 for the first line?

Actually the <pre> contains all the lines at once separated by \n. But I can add a check. :)

Also, the line numbers are a "hidden" feature (not enabled by default) and were not tested before this test (not great...). Considering it will be the only existing test for this feature, I think it makes sense to have one strict test to ensure it won't be forgotten and that any change that would impact it actually need to see why it broke.

Checking unrelated properties (like border radius) doesn't make a test better, it just makes it more fragile. Fragility causes a test to fail when someone changes something, but didn't actually break anything.

I think of tests like an alerting system: If they alert all the time, maintainers and contributors (a) get warning blindness, (b) start to disrespect the tests, and (c) start to mechanically update them whenever they fail, rather than looking at what actually caused them to break.

You don't want your tests to signal "something changed;" you want them to signal "something broke."

Something changed in this case means that something broke. It also seems very unlikely that any of these properties changes unless you're working on code blocks. And in this case, you definitely want to be aware of this feature.

I removed the border-radius though since changing it wouldn't be a big issue...

Not everything that changes means something broke related to the line numbers. For instance: right now, the line numbers inherit their (calculated) font-size of 16em from a rule in normalize.css:

pre {
  font-size: 1em;
}

Imagine that changes to 2em. The will break a lot of our layouts, not just the line numbers. If that's something we're worried about (I don't think we are), we would want one test to fail: a test that checks that the contents of our <pre> tags are the right size. If instead a handful of tests about different features, like line numbers, failed, that would be very confusing and would result in the PR author thinking our tests are not meaningful. They might even give up their PR in frustration.

Another example: you're testing for the font face. That's set for all code and pre by this rule in rustdoc.css:

code, pre, a.test-arrow, .code-header {
  font-family: "Source Code Pro",monospace;
}

If we consciously decide to switch fonts for our pre tags in the future, we know we're changing fonts - we don't need a line-numbers unit test to tell us "this specific pre tag, out of all our pre tags, had a changed font."

Makes sense, I removed these checks.